Deploying cloud infrastructure and software may include many customization factors that cloud customers must accommodate when on-boarding software onto the cloud. Specifically, each cloud node may be managed via specific providers, for example, CloudStack, OpenStack, etc. Further, the cloud node may use a specific hypervisor to manage the node, for example, KVM, XEN, VMWare, etc. For each combination of these properties a different software image may be required. Further, a different setup process may be required to install the image depending upon the various factors.
In the current state-of-the art, a customer that wants to deploy a given image at several cloud nodes must manage each independently. This requires manually accessing each cloud node and targeting the specific needs of each system. As a result, large applications installed on a distributed cloud may be very difficult and cumbersome to manage. Additionally, in a distributed cloud there may be considerable challenges in image distribution that arise from security limitations that may block access between certain cloud nodes and image servers.
Additional issues exist. For example, there are differences between the image registration parameters between the different providers, for example, CloudStack requires a network location identifier such an URL indicating where the image is stored while OpenStack requires an input stream. In another example, the cloud nodes might not be in the same DMZ (demilitarized zone or secure network segment) as the image server, which means that the cloud nodes might not be able to use the image URL to retrieve the image directly from the image server. Also, each cloud node might be in a different DMZ, so two cloud nodes might not have access to each other and so cannot pass the image URL from one cloud node to another.